Build is happening from commits under https://github.com/tlaurion/heads/tree/x230-maximized-fhd
CircleCI build https://app.circleci.com/pipelines/github/tlaurion/heads/694/workflows/9d351748-166a-4fa6-b0e4-7a08510cedcc/jobs/765

Artifacts will be there to test.

I can test this, can't remember which kit mine is but it works vanilla coreboot with the fhd variant

Build will take a while since only musl-cross cache can be reused; adding patches to coreboot invalidated the two fuller caches, so all boards needs to be recompiled.

So participants of #614: @n4ru @arl4223 @tslilc @computer-user123 @Thrilleratplay @Tonux599, you might want to read and understand what happened #614 (comment) while the build is successful (or fails)

You can come back to https://app.circleci.com/pipelines/github/tlaurion/heads/694/workflows/9d351748-166a-4fa6-b0e4-7a08510cedcc/jobs/765 artifact section in like 3 hours or ping me if it fails before then, or play around the PR if you find something weird in there.

I do not care about the ownership of this code. Please take it, change it, and recreate another PR that would supersede this one. As long as your commits are signed, that functional tested PR by one of FHD owner will get merged in.

Thanks. This was my tutorial attempt to make this community a bit more autonomous on their owned boards to create new board configs.

OMG. Another problem?
CircleCI stops after 5 hours of build time!?!

Rebase on master when PR resulting of #970 is ready and merged.

2df946f should be successful, rebased on master which tweaked CircleCI to build with 24 cores.

@Tonux599 check it out and report back :)

Damn. forgot to change path in coreboot config pointed to that board to proper initrd and bzImage... Rebuilding.

@tlaurion flashed and appears to work!

Commits will be squashed.

1rst commit shows how to upgrade board configs, coreboot configs to latest coreboot version.
Second commit reverts the changes for other boards so only the fhd one is based on coreboot (since other boards, like the t430, requires feedback on built roms prior of bumpping to coreboot 4.13 in other tickets: #944 #949 specifically).

Superseded but not included in #1015
Wondering if #944 (comment) is relevant here? @Tonux599 ?

What's the current process for building an x230 FHD ROM? Been a while and haven't been tracking as closely.

@n4ru just checked the current patchset and it seems that you could apply the patch over master and make BOARD=x230-maximized-fhd on a clean checkout.

The magic is in the patch, which creates a new board under coreboot 4.13

Checking the coreboot config, I'm pretty sure Qubes won't install since VBT is not activated under coreboot config.

Also note that this is maximized board config, so should be flashed externally through bottom and top ROM files, and the board config doesn't include HOTP support.

This is a bit off compared to master.
A quick diff between that board config and x230-maximized should show what was improved (coreboot/linux configs pointed per board config)

From a cloned coreboot tree:

git fetch https://review.coreboot.org/coreboot refs/changes/50/28950/22 && git format-patch -1 --stdout FETCH_HEAD

Results in:

From 06fe32bb5f65c784e7819b875c505fcceab11b99 Mon Sep 17 00:00:00 2001
From: Alexander Couzens <[email protected]>
Date: Sat, 19 Mar 2022 13:42:33 +0000
Subject: [PATCH] lenovo/x230: introduce FHD variant

There is a modification for the x230 which uses the 2nd DP from the dock
as the integrated panel's connection, which allows using a custom eDP
panel instead of the stock LVDS display.

There are several adapter boards present on the market and all of them
uses the same method of enabling the custom eDP panel.

To make this work with coreboot, the internal LVDS connector should be
disabled in libgfxinit. The VBT has been modified as well, which allows
brightness controls to work out of the box.

The modifications done to the VBT are:
- Remove the LVDS port entry.
- Move the DP-3 (which is the 2nd DP on the dock) entry to the first
  position on the list.
- Set the DP-3 as internally connected.

This has been reported to work with the following panels:
- LP125WF2-SPB4 (1920*1080, 12.5")
- LQ125T1JW02 (2560*1440, 12.5")
- LQ133M1JW21 (1920*1080, 13.3")
- LTN133HL10-201 (1920*1080, 13.3")
- B133HAN04.6 (1920*1080, 13.3")
- B133QAN02.0 (2560*1600, 13.3")

Other eDP panels not on this list should work as well.

Change-Id: I0355d39a61956792e69bccd5274cfc2749d72bf0
Signed-off-by: Alexander Couzens <[email protected]>
Signed-off-by: Felix Singer <[email protected]>
---
 src/mainboard/lenovo/x230/Kconfig             |  15 ++++++++-----
 src/mainboard/lenovo/x230/Kconfig.name        |   3 +++
 src/mainboard/lenovo/x230/Makefile.inc        |   5 +++++
 .../lenovo/x230/variants/x230_edp/data.vbt    | Bin 0 -> 4281 bytes
 .../x230/variants/x230_edp/gma-mainboard.ads  |  21 ++++++++++++++++++
 5 files changed, 38 insertions(+), 6 deletions(-)
 create mode 100644 src/mainboard/lenovo/x230/variants/x230_edp/data.vbt
 create mode 100644 src/mainboard/lenovo/x230/variants/x230_edp/gma-mainboard.ads

diff --git a/src/mainboard/lenovo/x230/Kconfig b/src/mainboard/lenovo/x230/Kconfig
index a6fd796206..7aa5af6d85 100644
--- a/src/mainboard/lenovo/x230/Kconfig
+++ b/src/mainboard/lenovo/x230/Kconfig
@@ -1,4 +1,4 @@
-if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T || BOARD_LENOVO_X230S
+if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T || BOARD_LENOVO_X230S || BOARD_LENOVO_X230_EDP
 
 config BOARD_SPECIFIC_OPTIONS
 	def_bool y
@@ -11,7 +11,7 @@ config BOARD_SPECIFIC_OPTIONS
 	select H8_HAS_BAT_TRESHOLDS_IMPL
 	select H8_HAS_PRIMARY_FN_KEYS if BOARD_LENOVO_X230S
 	select NO_UART_ON_SUPERIO
-	select BOARD_ROMSIZE_KB_12288 if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T
+	select BOARD_ROMSIZE_KB_12288 if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T || BOARD_LENOVO_X230_EDP
 	select BOARD_ROMSIZE_KB_16384 if BOARD_LENOVO_X230S
 	select HAVE_ACPI_TABLES
 	select HAVE_OPTION_TABLE
@@ -20,7 +20,7 @@ config BOARD_SPECIFIC_OPTIONS
 	select INTEL_INT15
 	select DRIVERS_RICOH_RCE822
 	select MEMORY_MAPPED_TPM
-	select MAINBOARD_HAS_TPM1 if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T
+	select MAINBOARD_HAS_TPM1 if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T || BOARD_LENOVO_X230_EDP
 	select MAINBOARD_HAS_LIBGFXINIT
 	select GFX_GMA_PANEL_1_ON_LVDS if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T
 	select INTEL_GMA_HAVE_VBT
@@ -51,17 +51,20 @@ config MAINBOARD_DIR
 	default "lenovo/x230"
 
 config VARIANT_DIR
-	default "x230" if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T
+	default "x230" if BOARD_LENOVO_X230 || BOARD_LENOVO_X230T || BOARD_LENOVO_X230_EDP
 	default "x230s" if BOARD_LENOVO_X230S
 
 config MAINBOARD_PART_NUMBER
-	default "ThinkPad X230" if BOARD_LENOVO_X230
+	default "ThinkPad X230" if BOARD_LENOVO_X230 || BOARD_LENOVO_X230_EDP
 	default "ThinkPad X230t" if BOARD_LENOVO_X230T
 	default "ThinkPad X230s" if BOARD_LENOVO_X230S
 
 config OVERRIDE_DEVICETREE
 	default "variants/\$(CONFIG_VARIANT_DIR)/overridetree.cb"
 
+config INTEL_GMA_VBT_FILE
+	default "variants/x230_edp/data.vbt" if BOARD_LENOVO_X230_EDP
+
 config USBDEBUG_HCD_INDEX
 	int
 	default 2
@@ -83,4 +86,4 @@ config PS2M_EISAID
 config THINKPADEC_HKEY_EISAID
 	default "LEN0068"
 
-endif # BOARD_LENOVO_X230 || BOARD_LENOVO_X230T ||  BOARD_LENOVO_X230S
+endif # BOARD_LENOVO_X230 || BOARD_LENOVO_X230T ||  BOARD_LENOVO_X230S || BOARD_LENOVO_X230_EDP
diff --git a/src/mainboard/lenovo/x230/Kconfig.name b/src/mainboard/lenovo/x230/Kconfig.name
index 1a01436879..e7290a12dd 100644
--- a/src/mainboard/lenovo/x230/Kconfig.name
+++ b/src/mainboard/lenovo/x230/Kconfig.name
@@ -6,3 +6,6 @@ config BOARD_LENOVO_X230T
 
 config BOARD_LENOVO_X230S
 	bool "ThinkPad X230s"
+
+config BOARD_LENOVO_X230_EDP
+	bool "ThinkPad X230 eDP Mod (2K/FHD)"
diff --git a/src/mainboard/lenovo/x230/Makefile.inc b/src/mainboard/lenovo/x230/Makefile.inc
index 8e801f145d..6e6f9f90b9 100644
--- a/src/mainboard/lenovo/x230/Makefile.inc
+++ b/src/mainboard/lenovo/x230/Makefile.inc
@@ -5,4 +5,9 @@ bootblock-y += variants/$(VARIANT_DIR)/gpio.c
 romstage-y += variants/$(VARIANT_DIR)/early_init.c
 romstage-y += variants/$(VARIANT_DIR)/gpio.c
 ramstage-y += variants/$(VARIANT_DIR)/hda_verb.c
+
+ifeq ($(CONFIG_BOARD_LENOVO_X230_EDP),y)
+ramstage-$(CONFIG_MAINBOARD_USE_LIBGFXINIT) += variants/x230_edp/gma-mainboard.ads
+else
 ramstage-$(CONFIG_MAINBOARD_USE_LIBGFXINIT) += variants/$(VARIANT_DIR)/gma-mainboard.ads
+endif
diff --git a/src/mainboard/lenovo/x230/variants/x230_edp/data.vbt b/src/mainboard/lenovo/x230/variants/x230_edp/data.vbt
new file mode 100644
index 0000000000000000000000000000000000000000..13384d45571ff76e592335143d01315e37893186
GIT binary patch
literal 4281
zcmdT`Z)_aZ5&ym0y}P}=-MjTVC6^<yCLz$XvE%h&S*h!)@6LAcg^PXugKH2XcDRE^
zHNiLuN+i^5TbBk=p_5vr0Ri$CB!v1Q6%yhL5TS}%ZG|E}(5mW(6!8It5AdN?tBP`+
zx3_i!7V#AnmCow7GdpkI?0YkBW_RywafYVHi@l}UV$Y$8VyQezRd{&CInDRYR4h$Q
zA08>p6b={56T^4V^SA+LolmX+RUx+79#iSqiP~ars*|P{j#W<|Sw32Qpw?S@B$TK!
zT%y8#_th3_%L^xJRhpi?y+F#XZ5B@+U98gh$p??rmIq1sVr%N_-*;O-QJ>e_m+#Gc
zeSJjvzQO*1!F<1Mj*JdZ9IBMcg_+XCI898^NNKt-Jw1A;SiXxYQxjvQVrgb{#5RMi
z3_rAVdim%B-#tOO;ZDl)3wi>F!IEkCq2;B0R9IZ3DP?n<rfSD)%a7Em`)pG=xClcR
zfQTY3AQJz|BVh>3(8mm!Gbk$bf{?ofjp)+WX;f0xKuMreM_FPop&M`zu|-4&b{lx}
z6dXr%nIN^a1Q1g^?g`SApyQo+We^Ju;y^Soa0Kxp0ExE)gG^{(s5wk=5)@Iwe?zpD
z@%1v$crW@+c=`T;{ewfYIC5a@V7W3iGdp+pJ^l}V_@k99K7NB27i?KEp$JF`50mi@
zjG1XXrseRG7Qw69ek|x~_*Klqd$9}}jBGpu*K}~RX~1KAld;P%uwb}2&iFCo7mQyT
zCSGP-Wc-%#2gY9*A29yLh$l?6F>Yks%;;r&gE7oF#P|+lf$=@YNyZt*<BXp%o@K;N
z;^Rid2d9zA7a?zJayUAk?1cYJsDCEZCq4>N3Nz%%kOxj$xHTH_I6i5-#j$7@-%=}(
z?1954MnX?xAuk79(<<Tf409Fpx$wEsNX+wNp0De7H-87y*XOlHqw#v9f#_UhUAnlg
zi_2(JC*w<@<i}S-iI)}-&;1HW$=_hN&+7=v86dSJ5nbA)_y+kbU2PDFE??VVW9GW>
zSr6;_4gTc~tacpa=As!xD;@CT7xX)U4}W57_`9~2N<i$1-Hq?ZdXRnseAKTSC4vUn
zvU_KR`>pCP65!^@JyGbYMG6B#@{r1i&qF#431THdvdmK?gb!}@x&d86kH8RtSun)L
zMg&qo8p@sxlqPr)H*t1i5Xc8fNK*dW_}wA77I--u)J{nAs;))bo<l6#G>8v<p5gy;
z<c2$V&sxyMI7lIRD=DCSpmMmfaICgCzVKkJ#fR-<sP2F);1(})cA)7k<8|TuBs}RY
zwKp{#FZ7<eJej>k&YfS^jD1^rM=s>0ytuB(<S=kXYsT9eI1^R*2UrsIpx#)DflmYL
zcI2=F|Kw{2>VlIOTx;M223I$qhjl3%0pyLp$ECQ*_^UYE{?(M!zFMP3W9I<gN%(cT
zyvs4>_cUj9w4&M7&s8K0k<cwUM!E2PTu7mct3rr`5sB*7)nZ4R`hWT~<uZuic%Tb%
z5{?q{&YwfGl9W%nBS~{SNhgx-V@b1~q?eQKTGD(wN&iT?re$ukXwY)YmN{$Dqn7)m
zWuCX_HOswZnSZhfw(HvFPMeChJ7b&o+O%T3=WKJ;rZ;W(kGA=)O-9Pirp&!5I+$|r
zNtySj=%*?7xs>@rirz}Oms94I6gg>kPulEG+g%^&e&n+7+xV#SfijjY{5o+C7V}H-
zZs9PGrN7SK-OZ8YGZ>yr(&i#tdss~q`sQ|0&fnIIOUJ;O2*-=b;v=kW?O}6KsoH4P
z0smI&%EQn#cd@w$RZTVP=TtP?l7~|?nRTSIQO2qkgO+Z!=3#T$D-XeMvn68}T3Ey8
zHleye(7mkLXe*JtfA{Q*lj!gc)Wck4IFj|C#q&~HiNmA&>Z|kF4(U<Y;5eIloj)C%
zP4#WvIv2Sie|71?P3)md%>vj%v~DWNT8*x>a2}rST)i~8vd61DwO!2$JZMNNi6hyH
z2d_)6&979w%w$-vyatVrqw??t&t%}iZhDAP3%j_I#cGANdzLq>W;J(F=Xwkxxj%^H
zwQDmn=w}|@-y`RG{*wz0>A(ZGtk~AM=#-fE(LV1uZE98+Nk>UmiyyuJ8?##<Mr{1g
p(B@uj-Va_SU#<T#GXLCvin_ms#}9BYOE7UKDyX7coWuJX{tbC=%boxL

literal 0
HcmV?d00001

diff --git a/src/mainboard/lenovo/x230/variants/x230_edp/gma-mainboard.ads b/src/mainboard/lenovo/x230/variants/x230_edp/gma-mainboard.ads
new file mode 100644
index 0000000000..f7cf0bc264
--- /dev/null
+++ b/src/mainboard/lenovo/x230/variants/x230_edp/gma-mainboard.ads
@@ -0,0 +1,21 @@
+-- SPDX-License-Identifier: GPL-2.0-or-later
+
+with HW.GFX.GMA;
+with HW.GFX.GMA.Display_Probing;
+
+use HW.GFX.GMA;
+use HW.GFX.GMA.Display_Probing;
+
+private package GMA.Mainboard is
+
+   ports : constant Port_List :=
+     (DP1,
+      DP2,
+      DP3,
+      HDMI1,
+      HDMI2,
+      HDMI3,
+      Analog,
+      others => Disabled);
+
+end GMA.Mainboard;
-- 
2.30.2

Missing bits should be added in the patch under this PR.

Patch refuses to apply git created binary patch above...

@computer-user123 question here would be to know if you needed vbt in your rom

Edit: referred issue shows you added it manually. So vbt is needed. Got my answer here, where I guess @Tonux599 test was prior of Qubes 4.1 installer (current tested PR for x230-fhd didn't include vbt)

So next step is to change Make file patch tool reference to git, see below

Patch above coming from more recent changeset https://review.coreboot.org/c/coreboot/+/28950

But cannot be applied with patch because vbt file is binary.

It seems that we just hit our first corner case where global Makefile will need to use git instead of patch to apply binary patches, since patch still don't know how to apply binary diff even if we just want to create a binary file:

lenovo/x230/variants/x230_edp/data.vbt

Which in above patch description is required for:

The VBT has been modified as well, which allows brightness controls to work out of the box.

Otherwise not created, as in this PR.

The modifications done to the VBT are:

• Remove the LVDS port entry.
• Move the DP-3 (which is the 2nd DP on the dock) entry to the first position on the list.
• Set the DP-3 as internally connected.

Also, coreboot changeset is still not merged, but:

This has been reported to work with the following panels:

• LP125WF2-SPB4 (1920*1080, 12.5")
• LQ125T1JW02 (2560*1440, 12.5")
• LQ133M1JW21 (1920*1080, 13.3")
• LTN133HL10-201 (1920*1080, 13.3")
• B133HAN04.6 (1920*1080, 13.3")
• B133QAN02.0 (2560*1600, 13.3")

Other eDP panels not on this list should work as well.

• PR to change Make patch references to use proper git apply (might break things but doubtful)

Yet again, this is not nitrocaster mod, which doesn't need any firmware mod.

@n4ru applies or not? Willing to do the Makefile PR to switch patch calls to git?

From my understanding it "should" be as simple as replacing patch references with git --unsafe-paths

From https://git-scm.com/docs/git-apply.html

--allow-binary-replacement
--binary

Historically we did not allow binary patch applied without an explicit permission from the user, and this flag was the way to do so. Currently we always allow binary patch application, so this is a no-op.

--unsafe-paths

By default, a patch that affects outside the working area (either a Git controlled working tree, or the current working directory when "git apply" is used as a replacement of GNU patch) is rejected as a mistake (or a mischief).

When git apply is used as a "better GNU patch", the user can pass the --unsafe-paths option to override this safety check. This option has no effect when --index or --cached is in use.

I'll be able to test this later tonight.

@Tonux599 @computer-user123 @n4ru :
I changed the title to FHD (Not Nitrocaster) since I've read that that mod didn't required any firmware mod.
Since i'm not an owner of any of those mods, I would love to hear what that mod part is and if the name of this PR should be modified accordingly

@n4ru @computer-user123 : if you already flashed a maximized board before, you can flash internally the ROMs produced by CircleCI for each commit following https://osresearch.net/Downloading

Of course, you should only do that if you own an external programmer to be able to revert to taken backups. As said everywhere else, you cannot flash maximized boards from 1vyrain blahblablah, this requires initial external flashing.

I will check to make sure this PR works, tracing CircleCI fresh build with patches applied by git here (see Makefile changes).
This will probably result into a single individual PR just for Makefile changes, and this PR will be rebased on master after that PR works. But as of now, be precautious flashing roms coming from this PR. Some patches might not be applied as expected because of Makefile changes.

Following x230-hotp-maximized build that is happening under https://app.circleci.com/jobs/github/tlaurion/heads/8346?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link where full build log is at https://circleci.com/api/v1.1/project/github/tlaurion/heads/8346/output/103/0?file=true&allocation-id=62f67dfd11f310285d2a0333-0-build%2F2DC2F74E.

Patching with git seems to be functional and my local tests were exiting early, but I only tested by removing build/coreboot-4.13 and adapting the patch so that no rejection was made, to adapt Makefile to be able to apply binary patches with --directory pointing to relative path from git local dir. Otherwise it was failing silently (weird). Hacks found online where to create local git init in extracted dir when not a git repository, where forcing --directory seemed to be the cleaner approach, but now we expect to by under git dir, where some modules change directories to do make kung fu. Hopefully everything will work as expected.

If you have something cleaner then this patch against Makefile, please tell me: 8adca9a

Seems to be ok as of now, but it is still early to tell, with linux having been extracted and coreboot being built:

if [ -r patches/coreboot-4.13.patch ]; then ( git apply --verbose --reject --binary --directory build/coreboot-4.13 ) < patches/coreboot-4.13.patch || exit 1 ; fi
if [ -d patches/coreboot-4.13 ] && [ -r patches/coreboot-4.13 ] ; then for patch in patches/coreboot-4.13/*.patch ; do echo "Applying patch file : $patch " ; ( git apply --verbose --reject --binary --directory build/coreboot-4.13 ) < $patch || exit 1 ; done ; fi
Applying patch file : patches/coreboot-4.13/0002-x230-fhd-variant.patch 
Checking patch build/coreboot-4.13/src/mainboard/lenovo/x230/Kconfig...
Checking patch build/coreboot-4.13/src/mainboard/lenovo/x230/Kconfig.name...
Checking patch build/coreboot-4.13/src/mainboard/lenovo/x230/Makefile.inc...
Checking patch build/coreboot-4.13/src/mainboard/lenovo/x230/variants/x230_edp/data.vbt...
Checking patch build/coreboot-4.13/src/mainboard/lenovo/x230/variants/x230_edp/gma-mainboard.ads...
Applied patch build/coreboot-4.13/src/mainboard/lenovo/x230/Kconfig cleanly.
Applied patch build/coreboot-4.13/src/mainboard/lenovo/x230/Kconfig.name cleanly.
Applied patch build/coreboot-4.13/src/mainboard/lenovo/x230/Makefile.inc cleanly.
Applied patch build/coreboot-4.13/src/mainboard/lenovo/x230/variants/x230_edp/data.vbt cleanly.
Applied patch build/coreboot-4.13/src/mainboard/lenovo/x230/variants/x230_edp/gma-mainboard.ads cleanly.
Applying patch file : patches/coreboot-4.13/0080-util-crossgcc-builgcc_temp_fix_from_https_to_http.patch 
Checking patch build/coreboot-4.13/util/crossgcc/buildgcc...
Applied patch build/coreboot-4.13/util/crossgcc/buildgcc cleanly.

if [ -d patches/linux-4.14.62 ] && [ -r patches/linux-4.14.62 ] ; then for patch in patches/linux-4.14.62/*.patch ; do echo "Applying patch file : $patch " ; ( git apply --verbose --reject --binary --directory build/linux-4.14.62 ) < $patch || exit 1 ; done ; fi
Applying patch file : patches/linux-4.14.62/0000-efi_bds.patch 
Checking patch build/linux-4.14.62/arch/x86/boot/compressed/eboot.c...
Checking patch build/linux-4.14.62/arch/x86/boot/compressed/early_serial_console.c...
Applied patch build/linux-4.14.62/arch/x86/boot/compressed/eboot.c cleanly.
Applied patch build/linux-4.14.62/arch/x86/boot/compressed/early_serial_console.c cleanly.
Applying patch file : patches/linux-4.14.62/0001-fake-acpi.patch 
Checking patch build/linux-4.14.62/drivers/acpi/acpica/evxfevnt.c...
Checking patch build/linux-4.14.62/drivers/acpi/acpica/hwacpi.c...
Applied patch build/linux-4.14.62/drivers/acpi/acpica/evxfevnt.c cleanly.
Applied patch build/linux-4.14.62/drivers/acpi/acpica/hwacpi.c cleanly.
Applying patch file : patches/linux-4.14.62/0002-nmi-squelch.patch 
Checking patch build/linux-4.14.62/arch/x86/kernel/nmi.c...
Hunk #1 succeeded at 292 (offset -11 lines).
Hunk #2 succeeded at 302 (offset -11 lines).
Applied patch build/linux-4.14.62/arch/x86/kernel/nmi.c cleanly.
Applying patch file : patches/linux-4.14.62/0003-fake-trampoline.patch 
Checking patch build/linux-4.14.62/arch/x86/realmode/init.c...
Hunk #1 succeeded at 37 (offset 2 lines).
Hunk #2 succeeded at 151 (offset 13 lines).
Applied patch build/linux-4.14.62/arch/x86/realmode/init.c cleanly.
Applying patch file : patches/linux-4.14.62/0010-winterfell-ahci.patch 
Checking patch build/linux-4.14.62/drivers/ata/libahci.c...
Hunk #1 succeeded at 543 (offset 6 lines).
Applied patch build/linux-4.14.62/drivers/ata/libahci.c cleanly.

@JonathonHall-Purism so yeah, we could remove --binary from latest tests. But not --reject.

Merge?

Ah @tlaurion I didn't realize we were using git apply to patch tarballs, OK definitely no --3way then.

I think you have --reject backwards though. TL;DR though, the build will fail with or without --reject. I'm good with merging this either way.

From my understanding, we want rejet and the build to fail right there. No?

IIUC, the default behavior is to "reject the entire patch":

For atomicity, git apply by default fails the whole patch and does not touch the working tree when some of the hunks do not apply.

With --reject, it will still apply as much as it can and only reject individual hunks. The name is somewhat confusing though:

This option makes it apply the parts of the patch that are applicable, and leave the rejected hunks in corresponding *.rej files.

The exit code though isn't mentioned in the man page. I just checked and it exits unsuccessfully with or without --reject, so either way should be fine. I had thought that it might still be successful if it drops individual hunks to .rej files (with --reject) since this is what --reject asked for, but it turns out it fails either way.

So with or without --reject is fine - only difference is what you would see in the build output after a failed build.

Depends on #1201 being merged, and rebasing of this PR on master.

@tlaurion Only change I needed to get it to compile in #1299 was modify the config files to have BLOB_DIR and BOARD_BUILD_DIR over the dot back paths.

CircleCI building rebase under https://app.circleci.com/pipelines/github/tlaurion/heads?branch=x230-maximized-fhd_rebase commited under https://github.com/tlaurion/heads/tree/x230-maximized-fhd_rebase branch to see if building of new boards are successful as-is.

Next steps (not directly related):

• Next run of changes: remove coreboot configs, have board configs point to shared coreboot config for a shared coreboot config across boards (single x230-maximized board should enough across all x230-maximized. single x230-maximized-edp shared across x230-edp variant should be enough. same for other board configs shared coreboot configs not requiring coreboot specific changes).
• xx20/xx30 maximized coreboot configs: Fix CONFIG_CBFS_SIZE to reflect ifd.bin's BIOS region (xx20: gain of 0.59mb, xx30: gain of 0.4mb #1298 will need to also patch new coreboot configs deployed here after merge of this PR.

Notes:

• We can reuse the same coreboot configs for different board variants as of today, since BLOBS_DIR and BOARD_DIR are now variables expended from Makefile.
• Also noted that board configs should extend basic boards configs (here x230-maximized), only containing aesthetic differences (eg. BOARD_NAME) and board specifics changes needed to boot platform differently (eg: KERNEL_ADD).

@echo-84 sorry for the spam (config was not pointing to vbt by unfixed review at https://review.coreboot.org/c/coreboot/+/28950/22#message-4904ce82f01ba0505b391e072e4537b6a9f1a229 which is last commit 2b05a6b. This is a rebase on top of master.

If you could test new added board's rom from this PR and confirm everything is right, I would merge.
Will point to direct roms in this post and tag other testers above when done.

Build on clean checkout (without reusing CircleCI caches layers from CircleCI config by overriding CACHE_VERSION under CircleCI project setting) happening at: https://app.circleci.com/pipelines/github/tlaurion/heads/1415/workflows/488017c4-6fd7-4a8a-86e8-133af566b2ee

• x230-maximized-fhd_edp artifacts
  • externally flashable bottom rom
  • externally flashable top rom
  • internal firmware upgrade (if already on maximized build) full rom
• x230-hotp-maximized-fhd_edp artifacts
  • externally flashable bottom rom
  • externally flashable top rom
  • internal firmware upgrade (if already on maximized build) full rom

Note that another commit will add additional freed space per #1298 once this PR is merged.

Also pinged upstream to (hopefully) have this merged under coreboot 4.19 to ease support of this coreboot board variant (I hate patching and associated maintainer's costs)

This is happening here: https://review.coreboot.org/c/coreboot/+/28950/comments/3e4d62ef_79715796

So @n4ru @computer-user123 @Tonux599 @househead : if you could also insist on upstream merge, would be nice.

A gentle reminder that the reason why boards get dropped and features are not merged is because not enough people participate in upstream projects. I do not own a FHD/eDP board, so I can only rely on your testing and have less power then the number of you telling coreboot that you need this :)

@echo-84 sorry for the spam (config was not pointing to vbt by unfixed review at https://review.coreboot.org/c/coreboot/+/28950/22#message-4904ce82f01ba0505b391e072e4537b6a9f1a229 which is last commit 2b05a6b. This is a rebase on top of master.

If you could test new added board's rom from this PR and confirm everything is right, I would merge. Will point to direct roms in this post and tag other testers above when done.

Build on clean checkout (without reusing CircleCI caches layers from CircleCI config by overriding CACHE_VERSION under CircleCI project setting) happening at: https://app.circleci.com/pipelines/github/tlaurion/heads/1415/workflows/488017c4-6fd7-4a8a-86e8-133af566b2ee

Note that another commit will add additional freed space per #1298 once this PR is merged.

No worries and sure, I'll test in a few days when I have access to my flashing setup in case anything goes haywire.

I'll also look into the upstream side; see what's going on there and what I can do to help with get it merged.

Flash was successful and it appears to be functioning properly.

I ran my own compile and was able to build successfully but I came out with a different hash. Only thing I could think of is that I have a different ME blob tho mines the same as README. Or possible different files pulled due to it being a day?

Also unrelated, I did manage to kernel panic and will open a bug with it but not really a big deal as the process to cause it shouldn't really happen unless you try to make it happen.

Only thing I could think of is that I have a different ME blob tho mines the same as README.

Final ROM hashes will be different if anything packed in ROM is different.

If ME is different, hash will be different as well. Under build dir, hashes.txt contains sha256sum hashes for everything Heads related (bzimage, tools.cpio and its packed tools, modules.cpio and kernel modules packed, heads.cpio containing everything git related from initrd dir and finally, all those 3 initrd cpio are packed under initrd.cpio.xz with its hash.

There is issue detailing more in detail how to investigate reproducibility issues, but pushing this forward individually (each modules/* should contain either proper make hacks to make sure rpath etc are overriden otherwise some path can bleed into the compiled binaries and causing discrepancy) or patches need to be applied on top of uncompressed tarballs to fix upstream tools reproducibility issues

@n4ru @computer-user123 @Tonux599 @househead: if you have any issue, please open an issue!